Features of the Systems Engineering Process Activities (SEPA) Methodology

The pre~nce of software systems within the manufacturing enterprise is significant and growing. The cost and complexity of software components must be controlled to maintain competitive operations. SEPA is a design methodology that creates traceable, comprehensible, and extensible component-based system design specifications based on requirements from system clients and domain experts. Through the application of Artificial Intelligence techniques, the SEPA tool suite presents itself as a unique tool offering among software development tools. 1. Motivation The presence of software systems within the manufacturing enterprise is significant and growing. Software is integral to factory floor operations: from inventory management systems, production planning and scheduling systems to shop and machine control. According to Gary Gettel, Director of Factory Integration at Sematech, software continues to play an ever-increasing role in manufacturing: Software content in equipment is growing by more than 25% per year. To prevent this increased amount of software complexity from derailing effective factory operation, more reliable, predictable fall-safe software will be required. Higher utilization of commercial software subsystems, greater maturity of the industry’s software development capability and reduced software customization through more configurable architectures will be needed. (Gettel 1998) The cost of installing and customizing commercial-offthe-shelf (COTS) software, developing in-house software systems, and integrating new software systems with existing systems can be enormous. In semiconductor manufacturing, for example, the cost of integration is often 3-10 times the basic cost of the manufacturing system product (Weber 1998). The difficulty in achieving manufacturing component integration is influenced by a number of factors, including ever-increasing process/factory complexity and the Copyright © 1998, American Association for Artificial Intelligence (www.aaai.org). All rights re,reed. interaction of multiple perspectives (e.g. technology, business, personal) (Weber 1998). Furthermore, it deceptively easy to underestimate the cost of software maintenance when planning a software budget. An often cited study by Schach places maintenance at 67% of total lifecycle costs, while the requirements and specification phases account for only 7% (Schach 1990). The premise of the research described in this paper is: Investment in formal, repeatable requirements analysis and verification will reap rewards in later phases in the lifecycle, specifically reduction in maintenance costs and support for integration of system components. 2. System Engineering Process Activities SEPA is a design methodology that creates traceable, comprehensible, and extensible system design specifications based on requirements from system clients and domain experts (Barber, Graser et al. 1998). The funnel abstraction is chosen (see Figure 1) to represent spectrum of user inputs/requirements that are narrowed, refined, and structured into a system design. As with many domains, software developers and integrators in the manufacturing domain aim to address a number of commonly recognized software engineering issues, including changing requirements, communication among stakeholders, adaptable architectures, and integration of COTS and in-house solutions. The SEPA methodology and tool suite focus on supporting such goals by providing: 1. defined deliverables to improve communication among stakeholders; 2. the use of multiple views on a variety of graphical knowledge models developed directly from knowledge acquisition; 3. a process for merging the knowledge models resulting from different domain experts yielding a unified set of user requirements; 4. a method for distinguishing between requirements relating to a specific system implementation and those relating to general domain knowledge; 5. support for requirements changes during development; 6. the designation of adaptable domain components based on responsibilities for services and tasks. The resulting reference architecture represents the domain Barber 9 From: Proceedings of the Artificial Intelligence and Manufacturing Workshop. Copyright © 1998, AAAI (www.aaai.org). All rights reserved. independent of implementation, allowing it to be used for a family of applications in the domain; 7. traceability and verification throughout he analysis and design process: and 8. early detection of component integration issues through a domain-based reference architecture